perm filename COMMEN[CLS,LSP] blob
sn#847459 filedate 1987-10-22 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00005 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 ∂21-Oct-87 2033 @STONY-BROOK.SCRC.Symbolics.COM,@EUPHRATES.SCRC.Symbolics.COM:Moon@STONY-BROOK.SCRC.Symbolics.COM First round of comments on the draft document
C00016 00003 ∂22-Oct-87 0837 skeene@STONY-BROOK.SCRC.Symbolics.COM My comments on Chapter 1
C00026 00004 ∂22-Oct-87 1037 Moon@STONY-BROOK.SCRC.Symbolics.COM Rest of comments on chapter 1 of the draft document
C00032 00005 ∂22-Oct-87 1108 Moon@STONY-BROOK.SCRC.Symbolics.COM Keene comments on Chapter 1
C00036 ENDMK
C⊗;
∂21-Oct-87 2033 @STONY-BROOK.SCRC.Symbolics.COM,@EUPHRATES.SCRC.Symbolics.COM:Moon@STONY-BROOK.SCRC.Symbolics.COM First round of comments on the draft document
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Oct 87 20:33:27 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 260598; 21 Oct 87 23:34:23 EDT
Date: Wed, 21 Oct 87 23:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: First round of comments on the draft document
To: Common-Lisp-Object-System@sail.stanford.edu
Message-ID: <19871022033419.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments on the 20 Oct 1987 16:34 draft of the CLOS documentation
pages 1-1 through 1-32.
I don't think we need the concept of "setf generic function" at all
any more. Such generic functions are now completely the same as
ordinary generic functions except that you get to them through
SYMBOL-FUNCTION of a name that is a list. I don't think we need
special mention of "setf generic functions" all over the place.
I would just say in the paragraph on 1-21 that begins "In Common
Lisp, a name can be given to a function...", something like
the following: "The name of a generic function, like the name of
an ordinary function, can be either a symbol or a two-element
list whose first element is {\bf setf} and whose second element
is a symbol. This is true for both local and global names."
The section "Introduction to Setf Generic Functions" can be completely
eliminated. If we want to publicize the recent cleanup that introduced
setf functions, we can attach that as an appendix; in any case, I think
this is better explained without reference to generic functions.
1-8 bottom of page: change two references to "setf method" to
"a method for writing the value of the slot", and then after
"appropriate generic functions" say the reading generic function
has a name specified in the defclass, while the writing generic
function is named (setf -reader-).
1-25 second paragraph: We don't need to make any distinction about
setf generic functions here; delete the paragraph.
================
The section title "Changing Classes" is poor. We aren't doing
anything to a class, we're doing something to an instance. A
more appropriate title would be "Changing the Class of an Instance".
================
We need to put in the glossary.
================
1-3 sixth paragraph: "ordered set" should be "list" in two places,
to avoid implying that duplicates are eliminated from the "set" of
parameter specializers or the "set" of qualifiers.
1-23 first paragraph under Introduction to Methods: same comment.
================
1-6 fourth paragraph: Clarify the range of n in the definition of
"superclass". I think you mean n >= 2, so that any "direct superclass"
is also a "superclass", but a class is not a superclass of itself.
================
1-8 bottom of page: "When a reader or accessor is specified for an
individual slot...": I don't understand what "individual" is in contrast to.
Every reader or accessor is for one slot, we don't have anything that
reads several slots and returns multiple values or anything like that.
If this sentence is just left over from the removal of :accessor-prefix,
we can just delete the sentence.
================
1-11 third bullet: we could just say "... union of the initialization
arguments declared in :initarg slot options in all the slot specifiers."
since all these bullets assume a set of slot specifiers for one name.
================
1-11 last sentence: needs to be updated with a correction I sent earlier,
because :default-initargs can appear more than once in a defclass.
================
1-15 last paragraph: It might be worth mentioning that the copy has dynamic
extent. This is mentioned in the remarks on 2-13, but it might be worth
repeating here.
================
1-16 fourth paragraph last sentence: "It is not allowed" is not defined
in the error terminology section. I think you mean "CLOS may be
extended to cover make-instance of a standard-type class or inclusion of
a standard type class as a superclass of a class."
================
1-18 last sentence: Actually a loop can contain more than two classes.
================
1-19 third paragraph last sentence: "will be followed by all classes
in T1", append "except t". The example could actually be generalized
to a join class J that isn't t, provided none of J's superclasses
appear elsewhere in the graph than above J. Then we have T1 up to
but not including J, followed by T2, ending in J and its superclasses.
================
1-23 last bullet: "(EQL -object-)" should be "(EQL -form-)", because
in a parameter specializer name, we have a form that is to be evaluated
to produce the object that appears in the parameter specializer. The
paragraph immediately following is wrong where it says "otherwise N
equals P" for this reason. We changed this when we changed QUOTE to EQL.
1-23 fourth paragraph: We no longer require parameter specializer names
to be Common Lisp type specifiers. (EQL -form-) is not a type-specifier.
================
1-23 last paragraph: I think the reference to make-instance here should
be changed to say specifically "make-instance of standard-method".
================
1-24 last paragraph: It's no longer true in the short form of
define-method-combination that primary methods can be unqualified.
Now, primary methods are qualified with the name of the type of
method combination, while auxiliary methods are qualified with :around.
================
1-32 first sentence: generic-flet, generic-labels, and with-added-methods
also accept a :method-combination argument.
================
1-32 first bullet last sentence: I don't understand why the word "only"
is present here. Maybe you mean "is supported only in :around methods
when a built-in" rather than "is supported in :around methods only when
a built-in"; i.e. does "only" modify ":around methods" or does it modify
"when"? Also, this sentence should probably be pulled out of the bullet
since I think it is saying something about both method roles. Maybe the
sentence should be deleted since the same information is repeated later
on the page.
================
OPEN ISSUES:
1-13 fourth paragraph: I think slot reinitialization should not be done
by a method for update-instance-structure. Instead it should be done at
the meta-object level, and defined to be completed before
update-instance-structure is called. This would be consistent with
change-class.
1-16 second paragraph: The specification about type-of here only applies
to instances of standard classes, or something like that. It certainly
doesn't apply to instances of all standard type classes. (Boy the
distinction between "standard class" and "standard type class" is
confusing! The two names always sound the same to me.)
1-17 I still think it's wrong for list to be more specific than symbol
in the CPL of null. Consider the print-object methods. Also consider
the introjection of symbol between list and sequence, a surprising CPL.
================
TYPOS:
1-7 bottom of page: "the generic function uninitialized-slot" should be
"the generic function slot-unbound".
1-9 last sentence: "invokes the function slot-value is to", "is" is
a typo.
1-15 third sentence: "When an instance is updated", "updated" should be
"changed".
1-15 fifth paragraph: Delete the whole paragraph, this was accidentally
copied from the "redefining classes" section.
1-19: "(food t)" should be "(food, t)" in two places. 1-20 also.
1-22 third paragraph: "defintions"
1-22: "a names of the form (setf name)"
1-22: "Consider setf form (setf ..." should be "Consider the form (setf ...".
1-23 first line: We haven't defined the term "setf macro". Could say
"a setf macro defined for name with defsetf or define-setf-method".
1-23 in the funcall: "#:temp-2" should be "#:temp-1".
1-25 bullet 4 last sentence: "in in" should be "in".
1-25 Section "Named Arguments...": In this section's title and text,
"named argument" should be "keyword argument". My fault: I forgot to
mail out a corrected version of this section when the terminology
was changed back.
∂22-Oct-87 0837 skeene@STONY-BROOK.SCRC.Symbolics.COM My comments on Chapter 1
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Oct 87 08:37:41 PDT
Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 260872; Thu 22-Oct-87 11:38:42 EDT
Date: Thu, 22 Oct 87 11:36 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: My comments on Chapter 1
To: rpg@SAIL.STANFORD.EDU
cc: common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <19871022153612.9.SKEENE@JUNCO.SCRC.Symbolics.COM>
In general, the spec seems to be coming together nicely. I think it
reads better than it used to, and the tone is quite consistent
throughout.
----------------
I found it somewhat distracting that hyphenated functions are split
across lines.
1-7, second group of bullets, bullet #2:
"appropriately named" should be deleted; it implies that there is a
heuristic that makes up an appropriate name for the accessor generic
functions.
1-7, second to last paragraph
Fix typo "unitialized". Actually, I suggest deleting the sentence
containing the typo. The sentence is: "When an uninitialized slot is
read, the generic function uninitialized-slot is invoked." That's too
much detail for the overview; it bypasses describing the default
behavior, which would be more appropriate for an overview. In any
case, I believe the previous sentence is sufficient.
1-10, second paragraph under "Inheritance of Slots and Slot Options"
The last clause says "all instances of C access that single slot"; I
suggest saying instead "all instances of C can access that single slot"
or "that single slot is accessible to all instances of C."
1-13, regarding the default method for update-instance-structure
I like Moon's suggestion that the default method doesn't do the work.
But if that suggestion is not accepted, we should mention that users
should write after-methods unless they want to prevent the default
method from occurring. This could go at the end of the fourth
paragraph. Also it would be better to move the sentence beginning
"Methods for update-instance-structure can be defined..." from the 3rd
paragraph to the 4th, where the rest of the discussion about writing
methods is.
1-15
I agree with Moon that a better name is "Changing the Class of an
Instance". I also think it's confusing to use the terminology "old
class" and "new class" here, because the terms are used very differently
in the previous section. In the previous section "old class" meant
"that class that is now obsolete". Here it means "the previous class
of the instance". Here the "old class" is still current; it isn't
obsolete. I think new terminology could make it more clear what the
difference is between "changing the class of an instance" and
"redefining a class" -- how about using C-1 and C-2 terminology. That
makes it more clear that C-1 is not "old" or "obsolete" in any way; it's
just a class like any other.
Last paragraph: add "The default primary method for class-changed does
nothing." near the end of the paragraph.
1-17, Figure 1-1
The column header "Superclasses" doesn't make it clear that the order of
these classes is from most to least specific. In my draft of this the
column header was "Class Precedence List", which did make this clear.
1-19, First Example
Should state explicitly that the goal is to determine the CPL for the
class pie.
1-21, 3rd paragraph
"Ordinary functions and generic functions are called with identical
syntax." I can't remember for sure, but I believe we decided that
generic functions must have at least one required argument. If so,
this is one (minor) syntactic difference between ordinary and generic
functions.
1-21, 4th paragraph
Last sentence implies you need to evaluate a set of forms (a set of
defmethods and possibly a defgeneric) to produce a generic function
object, whereas really the evaluation of only one such form would do it.
1-21, last sentence
What is meant by "defgeneric (etc) are said to define a generic
function"? Unless you define "define", this is too vague to mean
anything. And if "define" means "create a g-f object", then defmethod
ought to be mentioned too.
1-22, second paragraph, last sentence
Regarding exporting names of generic functions from packages, the clause
"if it is part of an external interface" implies there is a way to
actually specify an external interface. I suggest replacing that
phrase with "if desired".
1-22, fifth paragraph, last sentence
I suggest replacing "The lambda-list of the generic function is defined
to be congruent with the lambda-list of the new method." with "The
lambda-list of the generic function is derived from the lambda-list of
the new method"
1-22, second to last paragraph
Typo: "specifying a names of"
1-25, second to last paragraph
"it is rare to find a vector used as a qualifier" -- The tone of this
clause is inconsistent with the usual factual, dry tone of the spec.
Since it doesn't add anything to what was already said, we should delete
it.
1-26, last paragraph
Change "not by all methods" to "not by all methods for the generic
function".
1-29, last paragrpah
Split up this too-long sentence into two or more sentences.
1-30, Standard Method Combination
I think the standard method combination should have a name, such as
"standard-method-combination". That name should be able to be given
to the :method-combination option to defgeneric, etc. It should be
noted as one of the Built-in Method Combination types. Just because it
is the default doesn't mean that it shouldn't have a name.
1-31
We don't say here what happens if a generic function is called and
there is no applicable method at all. Presumably an error is signaled.
1-32, first bullet, last sentence
Replace this sentence with "Use of the function call-next-method is
supported in :around methods."
1-32, second bullet
Add this sentence "Use of the function call-next-method is not
supported in primary methods."
1-32, third paragraph (excluding bullets)
It looks weird to have the close paren alone on the line. Bad line
break.
∂22-Oct-87 1037 Moon@STONY-BROOK.SCRC.Symbolics.COM Rest of comments on chapter 1 of the draft document
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Oct 87 10:37:42 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 260975; Thu 22-Oct-87 13:38:45 EDT
Date: Thu, 22 Oct 87 13:38 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Rest of comments on chapter 1 of the draft document
To: Common-Lisp-Object-System@sail.stanford.edu
Message-ID: <19871022173842.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments on the 20 Oct 1987 16:34 draft of the CLOS documentation
pages 1-33 through 1-39.
1-33 second bullet: "It is not allowed" is not defined
in the error terminology section. I think you mean "CLOS may be
extended to cover make-instance of a standard-type class or inclusion of
a standard type class as a superclass of a class."
(same issue as 1-16).
1-33 second bullet second sentence: I would delete the word "user-defined",
as on p.1-16, or change it to "defclass-defined."
1-33 second bullet last sentence: Remove this, we finished figuring out
which CL types have corresponding classes.
================
1-33 last bullet: Do generic-flet, generic-labels, generic-function, and
with-added-methods use standard-generic-function as the default class of
the generic function they define? I think they do.
================
1-33 last sentence: CLOS provides several predefined method combination
types, so I would change this sentence to refer to method combination
types in general not having their own meta-objects, rather than specifically
mentioning the standard method combination type. But see open issue below.
================
1-34 through 1-39: I had already reviewed this section before, but I
read it again carefully. It's almost all okay.
1-35 second paragraph: Maybe "both purposes" would be better than
"more than one purpose", since "more than one" made me think there were
more than the two purposes listed and maybe I had missed something.
1-37 first line: I'd say "It is not recommended that :initform forms
or default value forms have side-effects other than creating new objects."
since some people consider allocating storage to be a side-effect.
1-39 last line: "approved" might be a better word than "validated", since
we are trying to imply that check-initargs would definitely not signal
an error for the default initialization arguments and therefore does
not need to see them.
================
OPEN ISSUES:
1-33 last sentence: Just the other day I had to put a kludge into a
Flavors tool, instead of doing something elegant, due to the fact that
in Flavors there are no meta-objects for method-combination types. In
this case, I wanted to know what the qualifiers for primary methods
were. Perhaps when the meta-object protocol is a bit more clearly
defined, we can add meta-objects for method-combination types, so that a
method-combination type can specialize the behavior of more functions
than just compute-effective-method.
================
TYPOS:
1-36 fifth paragraph second line: "to a produce a"
1-38 last bullet: The section name in the cross-reference is spelled slightly
differently here than on the previous page.
∂22-Oct-87 1108 Moon@STONY-BROOK.SCRC.Symbolics.COM Keene comments on Chapter 1
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Oct 87 11:08:22 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 261017; Thu 22-Oct-87 14:09:25 EDT
Date: Thu, 22 Oct 87 14:09 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Keene comments on Chapter 1
To: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <19871022153612.9.SKEENE@JUNCO.SCRC.Symbolics.COM>
Message-ID: <19871022180926.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 22 Oct 87 11:36 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
In general, the spec seems to be coming together nicely. I think it
reads better than it used to, and the tone is quite consistent
throughout.
I agree with this, but forgot to say so in my earlier comments. I may
be "madly" reviewing the document, but so far I haven't found anything
to make me mad. Chapter 1 seems to be in excellent shape and there
should be no problems finishing it. I'm about to start reading Chapter 2.
1-30, Standard Method Combination
I think the standard method combination should have a name, such as
"standard-method-combination". That name should be able to be given
to the :method-combination option to defgeneric, etc. It should be
noted as one of the Built-in Method Combination types. Just because it
is the default doesn't mean that it shouldn't have a name.
I strongly agree. The name should be just "standard" I think, rather
than the longer name, since the other m-c types have short names.
Method combination types aren't in the same namespace as anything else,
so they don't need to tack "-method-combination" onto the end of their
name to distinguish them.
1-31
We don't say here what happens if a generic function is called and
there is no applicable method at all. Presumably an error is signaled.
Should say that it calls no-applicable-method, and maybe mention that
the default method for that signals an error.